[レポート] SEC201 Proactive security: Considerations and approaches #reinvent #reinvent2022

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

セッション名 : Proactive security: Considerations and approaches

概要概要(機械翻訳) : セキュリティはAWSの最重要課題です。このセッションでは、ビルダーエクスペリエンスとセキュリティの間のパートナーシップは、すべての人が安全に出荷するのを助ける方法を発見してください。AWSのビルダーとセキュリティチームを支援するツール、メカニズム、およびプログラムについてお聞きください。最後に、お客様の組織で同じ原則を適用して、迅速かつ安全な出荷を容易にし、お客様を喜ばせる方法を学びます。

スピーカー : Sarah Berry, AWS Security Manager, AWS
Eric Docktor, VP, Amazon Software Builder Experience, Amazon Web Services

レポート

今日はまず、さまざまなチームが協力してセキュリティ組織を構築し、ソフトウェアの安全性を支援する方法について説明します。 開発者がセキュリティプロセスにおいてが感じる抵抗をなくすためのデータや情報についても説明します。
開発者が価値の高い活動に集中できるよう、差別化につながらない構築を最初から排除する方法についても説明します。
セキュリティプロセスにおけるビルダーエクスペリエンスを向上させるための、成功の評価方法についても説明します。

Every event is a learning opportunity

話を2021年12月9日に戻したいと思います。12月9日を覚えている人もいると思います。 log4j があらわにあった日です。
我々は全員でこの問題に対処しなければなりませんでした。
そして17,000人のソフトウェアエンジニアに、修正プログラムを展開するよう指示し、それを実行させました。
この17,000人の人間が、120万ステップの手作業を行いました。これは驚くべきことです。 手動ステップとは、パッケージのインポート、ビルドの開始、デプロイの開始など、あらゆるものを指します。

変更はたった1行だったことがわかります。どうしてたった1枚のシャツを作るために、17,000人もの人が参加しなければならないかと自問自答しました。

私たちは、すべてのソフトウェアチームが、コードとアプリケーションを深く所有することを望んでいます。ログを含むアプリケーションに関わる全てを理解してもらいたいと考えています。
それは Amazon の有名な Leadership Principles という原則なのですが、そのオーナーシップモデルがチームの奥深くまで物事の所有権を押し進めすぎて、冗長な作業を生み出していたことに気づきました。
そのため、そのイベントから一歩引いて、構築やデプロイメントに非効率性が生じている他の理由にも目を向けました。
その結果、より効率的にするために社内でやるべきことがあることに気づきました。もちろん、お客さまへの提供方法を妥協するつもりはありません。

Focus areas of the builder experience

今年の2月に私のチームを発足させました。どうすればもっと効率的になるか、開発者のためにより良いものを提供し、かつ自社の顧客にも提供できるようにするにはどうしたらいいか。
私たちは、6つの分野に重点を置いています。

まず第一に、ソフトウェアの管理コストと強制アップデートの管理コストを削減することです。
AWS がお客様に言っているのは、差別化されていない重い仕事をたくさん取り除くことです。 私たちのソフトウェア開発者にも同じことを言わなければならないのですが、彼らは興味がありませんでした。

2つ目の焦点は、メンテナンスやインフラ構築の手作業を減らすことです。
AWS サービスのローレベルでは CloudFormation のようなツールを使って循環的に作業を行うことができません。

3つ目の焦点は、ソフトウェア開発者が適切な抽象化レベルで構築できるようにすることです。
彼らが OS レベルで仕事をする必要はないのです。

4つ目の焦点です。私たちがどこが優れているのかを測定するチームを立ち上げました。
どのチームが特定の目標を達成できているか、どのチームが苦戦しているかを測定し、それを図解して、ツールに表示しました。

5つ目の焦点は、仕事を管理しやすくすることです。
当社のような規模の会社では、チーム横断的な問題があり、管理方法を効率化する必要があります。

そして6つ目、お互いに学び合う能力、社内研修、理解、変化、そして Amazon でのキャリアを成長させる、そのような能力を持っている組織を持つことです。
さまざまなテクノロジーがひとつ屋根の下に集まっていることは、前例のないことだと考えています。

AWS ownership model

これは、AWS の CISO である CJ Moses の言葉です。
「Service teams own the security of their service, AWS Security owns the security of AWS」
このオーナーシップモデルは私たちが AWS で活動するうえで非常に重要です。

このコンセプトは、ほとんどの方がご存知だと思います。
Amazon は ”Two-pizza” チームというコンセプトで運営されています。
1つのチームは2枚のピザを食べるのにちょうどいいくらい人数で構成されています。
チームが小さいので、より速く革新的に動け、社会的な制約を減らします。
これはコンウェイの法則に基づくもので、設計は組織構造をミラーするという考えです。

Proactive security mission

私が所属する組織はプロアクティブセキュリティで、開発者が安全にビルドできるよう支援しています。
Amazon が物理的な荷物を安全に発送しているように、AWS もセキュアなソフトウェアパッケージを提供しています。
セキュリティはカスタマーエクスペリエンスの基礎となる部分です。プロアクティブセキュリティは、開発者が適切な顧客体験を提供しながら、予定通りにサービスを開始することを可能にします。

Builder experience

この絵は本当に重要です。
セキュリティ専門家にとって、ソフトウェア開発ライフサイクルを理解することは本当に重要です。
AWS はこのライフサイクルを安全に行うためにどのような手助けができるでしょうか。 私たちは、かつて非常に孤立していたセキュリティレビュープロセスを、シフトレフトすることにしました。

ご存知かもしれませんが、Amazon の全てのサービス、全ての機能はバックワードドキュメントから始まります。 これは、脅威モデルを早期に作成するためで、シフトレスト文化の一端を担っています。
このコンセプトは素晴らしいと思っていますが、実際には開発チームの動く速度にセキュリティが対応しきれないこともあります。 そこで私たちは、創造的な解決策を考え出す必要があることを学びました。

はじめに AppSec レビュープロセスが立ち上げられていないというフィードバックを受けていました。そこで、高いセキュリティ基準を設けることなく、予定通りにチームを立ち上げることができるような目標を設定しました。

問題の特定にも時間がかかっていました。そのため、開発ライフサイクルの早い段階でリスクを特定する必要がありました。

セキュリティレビューのプロセスが少し一貫性に欠け、曖昧だと感じることがあると、開発者から言われていました。

私たちは、開発者とセキュリティチームの比率、ビジネスが新機能を立ち上げるスピード、ビジネスが拡大するスピードを念頭に置いています。
セキュリティ人材の採用は非常に難しく、またその育成も大変です。トレーニングや採用がボトルネックになっています。創造的な解決策を考えなければならないことは分かっていましたが、それは何だったのでしょうか。

私たちは、開発チームにセキュリティを組み込む必要があると判断しました。開発者をトレーニングしてセキュリティ専門家に成長させたいと考えました。
”Two-pizza” チームに1人、AppSec エンジニアを配置しました。私たちはこれを AWS Guardians プログラムと呼んでいます。

Guardians vs security engineers

Guardians 実際にどのような仕事をしているのでしょうか？
サービスチームがセキュリティレビューを通過できるように導く役割を担ってもらいたいと考えています。

アプリケーションセキュリティのレビュープロセスは非常にわかりにくく、初めて行うチームには難しいということを痛感しています。 そこで、Guardians がシェパードになって、何をすべきか、何を提供すべきかを指示できるようにしたいのです。

次に、「Low-Hanging Security Fruit」 (セキュリティー攻撃者が簡単に悪用できるもの) に対処できるようします。セキュリティエンジニアが複雑な設計上の考慮事項に集中できるようにするためです。

第3に、AWSセキュリティのアンチパターンを基本的に理解することです。

Guardians がいるからといってセキュリティエンジニアが不要なわけではありません。 セキュリティエンジニアはセキュリティの専門家です。 AWS は各サービスに1人のセキュリティエンジニアを割り当ています。

Impact of the Guardians program

このプログラムを開始してからのデータを見てみましょう。
2000 人以上のソフトウェア開発エンジニアに、セキュリティの考え方についてトレーニングを実施しました。
セキュリティレビューのプロセスを通じて、高および中程度の発見が22.5%減少し、数にして約16,000件減少しました。
セキュリティレビューの完了までの時間が 26.9パーセント短縮されました。これは、総所要日数が 21 万日以上短縮されたことを意味します。

How can you get started?

Guardians プログラムをどのように取り入れるか自分に問いかけています。

Guardians プログラムの最も優れた点は、ツールは一切必要ないことです。
多様な Guardians を設定し、組織の目標を設定します。その上で、必要なスキルと指導を与え、スタートです。

AWSは、脅威モデリングワークショップ Threat modeling the right way for builders を提供しております。
そこから継続的な知識共有のためのコミュニティを構築します。我々の開発者もセキュリティエンジニアもサイロ化された環境で仕事をすることを望んでいません。お互いに校正しあっています。
あなたの会社の社員にも同じことをするように勧めてください。

Guardians の効果を測定し、報告し、認識します。斬新的であろうと些細なことであろうと、リスクが環境に入り込まないようにすることが大切です。

そして最後に、継続的なフィードバックです。質的・量的データによる継続的なフィードバックの仕組みを構築する必要があります。

Builder experience

ソフトウェア開発ライフサイクルのスライドに戻りましょう。
ソフトウェアを管理したことがある人なら、これが本当の完全なライフサイクルでないことはご存知でしょう。

アプリケーションのライフサイクルは、もっとこのように見えます。 構築、設計、デプロイに費やす時間は、アプリケーションの寿命に対して非常に短い期間です。
アプリケーションが本番稼動するのはかなり長期に渡ります。(そう期待しているはずです) そして、本番稼動している間、あなたはそれを管理しなければなりません。

このとき、興味深いセキュリティの問題が発生します。というのも、顧客データへのアクセスを構築者に与えることなく、アプリケーションを稼働させ続けたいと思うからです。
そのため、構築したツールのひとつに、世界中の30のリージョンで、開発者が実際にログインすることなくソフトウェア・アプリケーションを管理できるようにする、という目標がありました。
ソフトウェア・ビルダーは、世界中のホストに SSH でアクセスすることを望んでいないのです。世界中のログをポーリングしたい、大規模なフリートを管理するツールがほしいと思うわけです。セキュリティの向上と効率化を同時に実現できる Win-Win な発想です。

What we built

私たちが社内で作った小さなツールをご紹介します。
このツールを「メカニック」と呼んでいます。これはAWSの運用を支援する下位レベルのツールの1つです。

メカニックには、3つのマジックビットがあります。その3つを紹介しましょう。

1つ目は、開発者にアクションを実行するための永続的なアクセス権を持たせないことです。
特定の問題に対して、誰が何にアクセスできるかを定義しておきます。そして、危機的状況下のみアクセス権を与えます。

2つ目は、本番環境のリソースに関するアクションはスクリプトで実行されます。
そのスクリプトは予め準備されており、コードレビューが済んでいる状態です。危機に対処するエンジニアはレビュー済みスクリプトを使用します。

3つ目は、本番環境で行われるすべてのアクションは、監査可能であるということです。
後から振り返ることが可能です。将来的には自動化することも考えられます。

AWS のツールを使えば同じようなことを行えます。

IAMをアクセス基盤として構築し、本番環境へのアクセスを許可しないようにすることが可能です。
AWS 環境への一時的な昇格アクセスの管理 を参照ください。どのように管理するか書いてあります。

本番環境で実行するスクリプトは、 Systems Manager を参照してください。 ここでは、あらゆるタイプのアプリケーションやサポートタスクのランブックを作成できます。 AWS でレビュー済みのランブックも用意されています。

Software assurance services

私たちは、Software Assurance Service (SAS) というツールを使っています。
セキュリティの脆弱性、コンプライアンス、可用性、あるいはソフトウェアビルダーとしての機能アップグレードなど、どんな理由であれ、最新の最高のソフトウェアを使っていることを保証するためのものです。

あるチームの例です。使用しているパッケージが時間とともに古くなっていきます。チームは「このパッケージは期限切れで、アップグレードが必要だ」と知る必要があります。 しかし、スプリントのなかでどうやってそれを拾えばいいでしょうか？ SAS はそのようなことを支援するツールです。

アプリケーションのなかで既知の CVE が含まれていれば、それを示すことができます。禁止されたセキュリティリスクである場合、パイプラインを停止しパッケージをアップグレードします。 ソフトウェアの展開を再開するかどうか判断できます。展開までの期限を表示することも可能です。

スクリーンショットの例では、開発者は Jackson-databind 2.1 を使用しようとしています。これには既知の脆弱性が含まれています。開発者は 2.1 より先へアップグレードしない限り、ソフトウェアを提出できません。
開発者が問題を発生させる前に、アップグレードの決断をするよう促しているのです。

AWS サービスを使って同じようなことができます。

Inspectorを使用すると、既知の脆弱性を持つソフトウェアを使用しないアプリケーションをスキャンできます。

サードパーティのビルドツール／パッケージマネージャを使っている場合は、Code Artifact がおすすめです。組織内で管理されたパッケージを使用可能です。

Maximize the deliverd customer value

当社の副社長で著名なエンジニアの Eric Brandwine が自動化について言っていることを取り上げましょう。
すべてのセキュリティシステムの目標は、提供するコストを最小限に抑えながら、提供する顧客価値を最大化することです。
開発者とセキュリティのパートナーシップでデリバリーに関わるコストを削減します。(上で説明している通りです) 私たちは、自動化を用いてこれを実現しています。

セキュリティ・レビュー・プロセスでは、常に4台のスキャナが稼動しています。
ウェブとAPIのエンドポイント解析、静的コード解析、リソース構成のテストを実施しています。
300以上のルールを社内で作成し、リソースとアカウントに対して実行しています。

AWS Security Workflow Automation Team と呼ばれる独自のチームがあり、チームが迅速にイノベートできるようにしています。繰り返し安全でコンプライアンスに準拠したサービスをリリースすることができています。

Talos

Talos を紹介します。
Talos のビジョンはセキュリティエンゲージメントプロセスを自動化することです。
Talosは、セキュリティレビューにさよならを言い、セキュリティエンゲージメントにこんにちはを言いたいのです。

開発者がライフサイクルの初期に Talos を使用します。
インタラクティブに質問に回答していくと、入力された内容に基づいて Talos は具体的で実行可能なセキュリティタスクを出力します。

私たちの目標は、リソースの取得プロセスやリアルタイムの列挙など、可能な限り自動化することです。

People respect what you inspect

開発チームが自動化できないばあい、私たちは自動化を支援したいのです。
どこを改善すれば良いか、判るようにしてあげたいと思っています。
こんな言葉があります。「人々はあなたが検査したものを尊重する (People respect what you inspect)」
だから、私たちは、彼らの検査を助けるツールを作りたいのです。

そこで、開発チームが、どれくらいの頻度でパイプラインがブロックされているかなどを確認できるように、解析ツールを作成しました。
このツールの導入事例があります。パイプラインがテストの不備でブロックされた頻度を示す指標を解析しました。そのチームはパッケージ更新をより頻繁に行うようになり、毎週ブロックされるパイプラインの数が6～7%減少しました。

What can you do next?

どうすれば今日から始められるか、サラと私は、私たちがアマゾンでやっていることをたくさん話しました。

取るべき重要なことを再確認したかったのです。
開発チームがセキュリティを確保できるようにしてください。

• 自動化する
• 簡単にする
• デフォルトで正しく設定できるようにする

所感

クリエティブな役割の人間にはクリエイティブに集中してもらう、ということがすべての始まりだと思います。
AppSec は重要な概念ですが、アプリケーション開発者のすべてが複雑なセキュリティ対策を身につける必要はありませんし、現実的はありません。
セキュリティを確保しつつ、アプリケーション開発の進捗を阻害しないためのヒントが盛り込まれたセッションでした。

AWS サービスやサードパーティツールを使って開発段階からセキュリティを取り入れる取り組みは、すでに日本でも広まっています。
これから AppSec (日本では DevSecOps のほうが有名かもしれません) を取り入れるチームの参考になれば幸いです。

参考

以上、吉井 亮 がお届けしました。